1
2
další
Jednoduše řečeno, git pull provede git fetch následovaný git merge.
Můžete kdykoli provést git fetch a aktualizovat větve vzdáleného sledování pod refs / remotes / /.
Tato operace nikdy nezmění žádnou z vašich místních poboček pod refs / heads a je bezpečná bez změny pracovní kopie. Dokonce jsem slyšel o lidech, kteří pravidelně běží git fetch v cron práci na pozadí (i když bych to nedoporučoval).
Git pull je to, co byste udělali, abyste místní pobočku aktualizovali pomocí své vzdálené verze a zároveň aktualizovali své další větve vzdáleného sledování.
Z dokumentace Git pro git pull:
Ve svém výchozím režimu je git pull zkratkou pro git fetch následovanou git merge FETCH_HEAD.
|
Když použijete pull, Git se pokusí automaticky dělat vaši práci za vás. Je kontextově citlivý, takže Git sloučí všechny stažené komitace do větve, ve které aktuálně pracujete. Pull automaticky sloučí komitace, aniž byste je nejprve zkontrolovali. Pokud své pobočky pečlivě nespravujete, můžete narazit na časté konflikty.
Když načtete, Git shromáždí všechny závazky z cílové větve, které ve vaší aktuální větvi neexistují, a uloží je do místního úložiště. Nezlučuje je však s vaší aktuální větví. To je zvláště užitečné, pokud potřebujete udržovat své úložiště aktuální, ale pracujete na něčem, co by se mohlo zlomit, pokud aktualizujete soubory.
Chcete-li integrovat závazky do své hlavní větve, použijete sloučení.
|
Je důležité porovnat filozofii designu git s filozofií tradičnějšího nástroje pro řízení zdrojů, jako je SVN.
Subversion byl navržen a sestaven s modelem klient / server. Existuje jedno úložiště, kterým je server, a několik klientů může načíst kód ze serveru, pracovat na něm a poté jej odevzdat zpět na server. Předpoklad je, že klient může vždy kontaktovat server, když potřebuje provést operaci.
Git byl navržen tak, aby podporoval více distribuovaný model bez nutnosti centrálního úložiště (i když určitě můžete použít, pokud chcete). Také git byl navržen tak, aby klient a „server“ nemuseli být online současně. Git byl navržen tak, aby si lidé na nespolehlivém odkazu mohli dokonce vyměňovat kód prostřednictvím e-mailu. Je možné pracovat zcela odpojený a vypálit CD pro výměnu kódu pomocí git.
Za účelem podpory tohoto modelu udržuje git místní úložiště s vaším kódem a také další místní úložiště, které zrcadlí stav vzdáleného úložiště. Tím, že si lokálně ponecháte kopii vzdáleného úložiště, může git zjistit potřebné změny, i když není vzdálené úložiště dosažitelné. Později, když budete potřebovat poslat změny někomu jinému, může je git přenést jako sadu změn z bodu známého vzdálenému úložišti.
git fetch je příkaz, který říká „aktualizovat moji místní kopii vzdáleného úložiště.“
git pull říká „přenést změny ve vzdáleném úložišti tam, kde si nechám svůj vlastní kód.“
Normálně to git pull dělá tak, že provede git fetch, aby místní kopie vzdáleného úložiště byla aktuální, a poté sloučení změn do vašeho vlastního úložiště kódu a případně do vaší pracovní kopie.
Při odběru je třeba mít na paměti, že na vaší pracovní stanici jsou často alespoň tři kopie projektu. Jedna kopie je vaše vlastní úložiště s vlastní historií potvrzení. Druhá kopie je vaše pracovní kopie, kde upravujete a vytváříte. Třetí kopie je vaše místní „mezipaměť“ kopie vzdáleného úložiště.
|
Zde je obrázek Olivera Steeleho, jak to všechno do sebe zapadá:
Pokud je dostatečný zájem, předpokládám, že bych mohl aktualizovat obrázek a přidat git clone a git merge ...
|
Jedním z případů použití git fetch je, že následující vám řekne jakékoli změny ve vzdálené větvi od vašeho posledního načtení ... takže můžete zkontrolovat před provedením skutečného načtení, které by mohlo změnit soubory ve vaší aktuální větvi a pracovní kopii.
git načíst
git diff ... původ
Viz: https://git-scm.com/docs/git-diff týkající se syntaxe dvou a tří teček v příkazu diff
|
Trochu mě stálo pochopit, v čem byl rozdíl, ale toto je jednoduché vysvětlení. master ve vašem localhost je větev.
Když klonujete úložiště, načtete celé úložiště do místního hostitele. To znamená, že v té době máte počátek / hlavní ukazatel na HLAVU a hlavní ukazující na stejnou HLAVU.
když začnete pracovat a uděláte závazky, posunete hlavní ukazatel na HEAD + vaše závazky. Ukazatel původ / hlavní však stále ukazuje na to, jaké to bylo při klonování.
Rozdíl tedy bude:
Pokud provedete git fetch, načte pouze všechny změny ve vzdáleném úložišti (GitHub) a přesune ukazatel origin / master na HEAD. Mezitím bude váš místní vedoucí pobočky stále ukazovat na místo, kde má.
Pokud provedete git pull, bude to v zásadě načíst (jak bylo vysvětleno dříve) a sloučit všechny nové změny do vašehohlavní větev a přesuňte ukazatel na HLAVU.
|
Někdy pomůže vizuální reprezentace.
|
Krátce
git fetch je podobný pull, ale nespojuje se. tj. načte vzdálené aktualizace (odkazy a objekty), ale vaše místní zůstane stejná (tj. původ / hlavní bude aktualizován, ale hlavní zůstane stejný).
git pull táhne dolů z dálkového ovladače a okamžitě sloučí.
Více
git clone klonuje repo.
git rebase uloží věci z vaší aktuální větve, které nejsou v předcházející větvi, do dočasné oblasti. Vaše pobočka je nyní stejná jako před zahájením změn. Takže git pull -rebase stáhne vzdálené změny, přetočí vaši místní pobočku, přehraje vaše změny v horní části aktuální větve jeden po druhém, dokud nebudete aktuální.
Také git branch -a vám přesně ukáže, co se děje se všemi vašimi pobočkami - místními i vzdálenými.
Tento příspěvek na blogu byl užitečný:
Rozdíl mezi git pull, git fetch a git clone (a git rebase) - Mike Pearce
a pokrývá git pull, git fetch, git clone a git rebase.
====
AKTUALIZACE
Myslel jsem, že to aktualizuji, abych ukázal, jak to skutečně využijete v praxi.
Aktualizujte místní repo ze vzdáleného (ale nesloučte):
git načíst
Po stažení aktualizací se podívejme na rozdíly:
git diff master origin / master
Pokud jste s těmito aktualizacemi spokojeni, sloučte:
git pull
Poznámky:
V kroku 2: Další informace o rozdílech mezi místními a dálkovými ovladači naleznete v tématu: Jak porovnat místní větev git s její vzdálenou pobočkou?
V kroku 3: Je pravděpodobně přesnější (např. Na rychle se měnícím repo) udělat zde git rebase origin. Viz komentář @Justin Ohms v jiné odpovědi.
Viz také: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
|
git-pull - Načíst a sloučit s jiným úložištěm nebo místní pobočkou
SYNOPSE
git pull…
POPIS
Spustí git-fetch s danými parametry a volá git-merge, aby se sloučil
načtené hlavy do aktuální větve. S --rebase volá git-rebase
místo git-merge.
Všimněte si, že můžete použít. (aktuální adresář) jako <úložiště> k vytažení
z místního úložiště - to je užitečné při slučování místních poboček
do aktuální větve.
Všimněte si také, že možnosti určené pro samotný git-pull a základní git-merge
musí být dány před možnostmi určenými pro git-fetch.
Tahali byste, pokud chcete sloučit historii, načetli byste, kdybyste jen chtěli codez, protože někdo zde označoval některé články.
|
Můžete načíst ze vzdáleného úložiště, zobrazit rozdíly a poté vytáhnout nebo sloučit.
Toto je příklad pro vzdálené úložiště s názvem origin a větev s názvem master, která sleduje původ / master vzdálené větve:
git pokladna master
git načíst
git diff origin / master
git rebase origin master
|
Krátká a snadná odpověď je, že git pull je jednoduše git fetch následovaný git merge.
Je velmi důležité si uvědomit, že git pull se automaticky spojí, ať se vám to líbí nebo ne. To by samozřejmě mohlo mít za následek sloučení konfliktů. Řekněme, že vaše dálkové ovládání je původ a vaše větev je hlavní. Pokud před taháním git diff origin / master, měli byste mít nějakou představu o možných konfliktech sloučení a podle toho byste mohli připravit místní pobočku.
Kromě tahání a tlačení některé pracovní postupy zahrnují git rebase, jako je tento, který parafrázuji z propojeného článku:
git pull origin master
git pokladna foo-větev
git rebase master
git push origin foo-větev
Pokud se ocitnete v takové situaci, může vás zlákat git pull --rebase. Pokud opravdu nevíte, co děláte, nedoporučoval bych to. Toto varování pochází z manuálové stránky pro git-pull, verze 2.3.5:
Toto je potenciálně nebezpečný režim provozu. Přepisuje se
historie, která neveští nic dobrého, když jste tuto historii publikovali
již. Nepoužívejte tuto možnost, pokud jste si nepřečetli git-rebase (1)
opatrně.
|
Dobře, zde jsou některé informace o git pull a git fetch, takže můžete pochopit skutečné rozdíly ... několika jednoduchými slovy, fetch získá nejnovější data, ale ne změny kódu a nezmění se s vaším aktuálním kódem místní pobočky , ale stáhněte si změny kódu a spojte je s místní pobočkou, čtěte dále a získejte další podrobnosti o každém z nich:
git načíst
Stáhne všechny odkazy a objekty a všechny nové pobočky do vašeho místního úložiště ...
Načíst větve nebo značky (souhrnně „odkazy“) z jedné nebo více
další úložiště, spolu s objekty nezbytnými k jejich dokončení
historie. Větve vzdáleného sledování jsou aktualizovány (viz popis)
způsobů ovládání tohoto chování níže).
Ve výchozím nastavení je jakákoli značka, která odkazuje na načítané historie
také načteno; výsledkem je načtení značek, které směřují na větve
zajímá vás. Toto výchozí chování lze změnit pomocí
možnosti --tags nebo --no-tags nebo konfigurací
remote..tagOpt. Pomocí refspec, která načte značky explicitně,
můžete načíst značky, které nesměřují do větví, které vás zajímají
stejně.
git fetch může načíst zbuď jedno pojmenované úložiště nebo URL, nebo
z několika úložišť najednou, pokud je dáno a existuje
dálkové ovladače. položka v konfiguračním souboru. (Viz git-config1).
Pokud není zadáno žádné dálkové ovládání, bude ve výchozím nastavení výchozí dálkový ovladač
použito, pokud pro aktuální není nakonfigurována upstream větev
větev.
Názvy refs, které jsou načteny, spolu s názvy objektů
ukazují na, jsou zapsány do .git / FETCH_HEAD. Tato informace může být
používaný skripty nebo jinými příkazy git, například git-pull.
git pull
Použije změny ze vzdálené na aktuální větev v místním ...
Zahrnuje změny ze vzdáleného úložiště do aktuální větve.
Ve výchozím režimu je git pull zkratkou pro git fetch následovanou
git merge FETCH_HEAD.
Přesněji řečeno, git pull spustí git fetch s danými parametry a
volání git merge sloučí načtené hlavy větví do proudu
větev. S --rebase spouští git rebase místo git merge.
by měl být název vzdáleného úložiště, jak byl předán
git-fetch1. můžete pojmenovat libovolný vzdálený ref (například
název tagu) nebo dokonce kolekce doporučení s odpovídajícími
větve vzdáleného sledování (např. odkazy / hlavy /: odkazy / dálkové ovladače / původ /),
ale obvykle je to název pobočky ve vzdáleném úložišti.
Výchozí hodnoty pro a jsou čteny z
"vzdálená" a "sloučená" konfigurace pro aktuální větev nastavená pomocí
git-branch --track.
Níže také vytvořím vizuál, abych vám ukázal, jak git fetch a git pull spolupracují ...
|
Toto interaktivní grafické znázornění je velmi užitečné při porozumění gitu: http://ndpsoftware.com/git-cheatsheet.html
git fetch jen "stáhne" změny ze vzdáleného do vašeho lokálního úložiště. git pull stáhne změny a sloučí je do vaší aktuální větve. "Ve výchozím režimu je git pull zkratkou pro git fetch následovanou git merge FETCH_HEAD."
|
Bonus:
Když mluvíme o pull & fetch ve výše uvedených odpovědích, rád bych se podělil o zajímavý trik,
git pull --rebase
Tento výše uvedený příkaz je nejužitečnějším příkazem v mém životě git, který ušetřil spoustu času.
Před odesláním nových revizí na server vyzkoušejte tento příkaz, který automaticky synchronizuje nejnovější změny serveru (pomocí fetch + merge) a umístí vaše potvrzení na začátek v git logu. Není třeba se obávat ručního vytažení / sloučení.
Podrobnosti najdete na: http://gitolite.com/git-pull--rebase
|
Rád bych měl nějaké vizuální znázornění situace, abych tyto věci pochopil. Možná by to rádi viděli i další vývojáři, takže tady je můj doplněk. Nejsem si úplně jistý, zda je vše správné, takže pokud zjistíte nějaké chyby, prosím o komentář.
MÍSTNÍ SYSTÉM
. ================================================== ===
==================. ==================================================
VZDÁLENÉ ÚLOŽIŠTĚ. DÁLKOVÉ KOPÍROVÁNÍ MÍSTNÍHO ÚLOŽIŠTĚ
(PŮVOD). (ULOŽENO)
například, . zrcadlo
repo github. . vzdálené repo
Může také být .
více repo.
.
.
FETCH * ------------------> *
Vaše místní mezipaměť dálkového ovladače je aktualizována s původem (nebo více
externí zdroje, to je distribuovaná povaha gitu)
.
SEM *------------------------------------------------ --------> *
změny jsou sloučeny přímo do vaší místní kopie. když dojde ke konfliktu,
jste požádáni o rozhodnutí.
.
SPÁCHAT . * <--------------- *
Když pocházíte například z podvracení, můžete si myslet, že se jedná o potvrzení
aktualizuje původ. V git se potvrzení provádí pouze pro místní repo.
.
PUSH * <--------------------------------------- *
Synchronizuje vaše změny zpět do počátku.
Některé hlavní výhody získaného zrcadla dálkového ovladače jsou:
Výkon (procházejte všemi závazky a zprávami, aniž byste se pokoušeli vniknout do sítě)
Zpětná vazba o stavu vašeho místního repo (například používám Atlassian's SourceTree, který mi dá žárovku označující, zda se dopustím dopředu nebo dozadu ve srovnání s původem. Tyto informace lze aktualizovat pomocí GIT FETCH).
|
Také jsem s tím bojoval. Ve skutečnosti jsem se sem dostal pomocí google vyhledávání přesně stejné otázky. Přečtení všech těchto odpovědí mi nakonec nakreslilo obrázek do hlavy a rozhodl jsem se to zkusit zjistit při pohledu na stav 2 úložišť a 1 pískoviště a akcí prováděných v průběhu času při sledování jejich verze. Takže tady je to, na co jsem přišel. Opravte mě, pokud jsem se kdekoli pokazil.
Tři repo s načtením:
--------------------- ----------------------- ------ -----------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - tlačí se - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------------------------------
- Místní repo - - Místní repo - - Místní repo -
- vytáhnout - - - - načíst -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Místní pískoviště - - Místní pískoviště - - Místní pískoviště -
- Pokladna - - nová práce - - -
- @ R01 - - @ R01 + - - @ R01 + -
--------------------- ----------------------- ------ -----------------
Tři reposy s tahem
--------------------- ----------------------- ------ -----------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - tlačí se - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Místní repo - - Místní repo - - Místní repo -
- tah - - - - tah -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Místní pískoviště - - Místní pískoviště - - Místní pískoviště -
- Pokladna - - nová práce - - sloučeno s R02 -
- @ R01 - - @ R01 + - - @ R02 + -
--------------------- ----------------------- ------ -----------------
To mi pomohlo pochopit, proč je načítání velmi důležité.
|
Rozdíl mezi GIT Fetch a GIT Pull lze vysvětlit pomocí následujícího scénáře:
(Mějte na paměti, že obrázky mluví hlasitěji než slova!, Poskytl jsem obrazové znázornění)
Vezměme si příklad, že pracujete na projektu se svými členy týmu. Bude tedy existovat jedna hlavní větev projektu a všichni přispěvatelé ji musí rozdat do svého vlastního místního úložiště a poté v této místní pobočce upravit / přidat moduly a poté se vrátit zpět do hlavní větve.
Tak,
Počáteční stav dvou poboček, když jste rozvětvili hlavní projekt ve vašem místním úložišti, bude takový - (A, B a C jsou moduly již dokončené v projektu)
Nyní jste začali pracovat na novém modulu (předpokládejme, že D) a až dokončíte modul D, chcete jej posunout do hlavní větve. Mezitím se ale stane, že jeden z vašich spoluhráčů vyvinul nový modul E, F a upravené C.
Takže teď se stalo to, že vaše místní úložiště chybí za původním vývojem projektu, a proto může prosazení vašich změn do hlavní větve vést ke konfliktu a způsobit poruchu vašeho modulu D.
Chcete-li se těmto problémům vyhnout a pracovat paralelně s původním průběhem projektu, existují dva způsoby:
1. Git Fetch - Tím se stáhnou všechny změny, které byly provedeny v projektu origin / main branch, které nejsou přítomny ve vaší místní pobočce. A počká, až příkaz Git Merge použije změny, které byly načteny do vašeho úložiště nebo pobočky.
Nyní tedy můžete soubory pečlivě sledovat a poté je sloučit do svého úložiště. A můžete také upravit D, je-li to nutné, kvůli změněnému C.
2. Git Pull - Tím se aktualizuje vaše místní pobočka s původní / hlavní větví, tj. Vlastně to, co dělá, je kombinace Git Fetch a Git sloučení jeden po druhém.
To však může způsobit konflikty, proto se doporučuje použít Git Pull s čistou kopií.
|
Jednoduše řekneme:
git pull == git fetch + git merge
Pokud spustíte git pull, nemusíte sloučit data s místními. Pokud spustíte git fetch, znamená to, že pro získání nejnovějšího kódu do místního počítače musíte spustit git merge. Jinak by se místní strojový kód nezměnil bez sloučení.
Takže v Git Gui, když načtete, musíte sloučit data. Samotné načtení neprovede změny kódu ve vaší místní síti. To můžete zkontrolovat při aktualizaci kódu načtením
jednou načíst a vidět; kód se nezmění. Pak sloučíte ... Uvidíte změněný kód.
|
git fetch stáhne kód ze vzdáleného serveru do vašich sledovacích větví v místním úložišti. Pokud je vaše dálkové ovládání pojmenováno origin (výchozí), budou tyto větve v rámci origin /, například origin / master, origin / mybranch-123 atd. Nejedná se o vaše aktuální větve, jedná se o místní kopie těchto větví ze serveru. .
git pull provede git fetch, ale poté také sloučí kód z větve sledování do vašeho aktuálníhomístní verze této větve. Pokud ještě nejste připraveni na tyto změny, stačí nejprve načíst git.
|
git fetch načte vzdálené větve, takže je můžete git diff nebo git spojit s aktuální větví. git pull spustí načtení na vzdálené brach sledované aktuální větví a poté sloučí výsledek. Pomocí git fetch můžete zjistit, zda jsou ve vzdálené větvi nějaké aktualizace, aniž byste je museli slučovat s místní pobočkou.
|
Git Fetch
Stahování změn do místní pobočky stáhnete od načtení. Fetch požádá vzdálené repo o všechny závazky, které udělali ostatní, ale nemáte je v místním repo. Fetch stáhne tyto závazky a přidá je do místního úložiště.
Git Sloučit
Změny stažené pomocí načtení můžete použít pomocí příkazu sloučení. Sloučit převezme závazky načtené z načtení a pokusí se je přidat do místní pobočky. Sloučení udrží historii potvrzení vašich místních změn, takže když sdílíte svou větev pomocí push, Git bude vědět, jak ostatní mohou sloučit vaše změny.
Git Pull
Fetch and merge run together often often that a command that combine the two, pull, was created. Pull provede načtení a poté sloučení a přidá stažené závazky do místní pobočky.
|
Jednoduše řečeno, pokud jste se chystali naskočit do letadla bez připojení k internetu ... před odletem byste mohli udělat git fetch origin . Načetlo by všechny změny do vašeho počítače, ale oddělte je od místního vývojového / pracovního prostoru.
V letadle můžete provádět změny ve svém místním pracovním prostoru a poté je sloučit s tím, co jste načetli, a vyřešit potenciální konflikty sloučení bez připojení k internetu. A pokud někdo neprovedl nové změny ve vzdáleném úložišti, pak jakmile dorazíte do cíle, uděláte git push origin a půjdete si dát kávu.
Z tohoto úžasného kurzu Atlassian:
Příkaz git fetch stáhne potvrzení, soubory a doporučení z a
vzdálené úložiště do místního úložiště.
Načítání je to, co děláte, když chcete vidět, co mají všichni ostatní
pracoval na. Je to podobné jako aktualizace SVN, protože vám to umožňuje vidět
jak ústřední historie pokročila, ale nepřinutí vás to
ve skutečnosti sloučit změny do vašeho úložiště. Git izoláty
načtený obsah jako ze stávajícího místního obsahu, má absolutně
žádný vliv na práci místního rozvoje. Načtený obsah musí být výslovně odhlášen pomocí příkazu git checkout. To dělá
načítání bezpečného způsobu kontroly závazků před jejich integrací s
místní úložiště.
Při stahování obsahu ze vzdáleného úložiště jsou k provedení úkolu k dispozici příkazy git pull a git fetch. Můžete zvážit
git načte „bezpečnou“ verzi těchto dvou příkazů. Stáhne se
vzdálený obsah, ale neaktualizovat pracovní stav místního úložiště,
ponechání vaší současné práce beze změny. git pull je agresivnější
alternativně stáhne vzdálený obsah pro aktivní místní
větev a okamžitě proveďte git merge a vytvořte sloučení
pro nový vzdálený obsah. Pokud probíhají nevyřízené změny
to způsobí konflikty a nastartuje řešení konfliktů sloučení
tok.
S git pull:
Nezískáte žádnou izolaci.
Nemusí to být výslovně odhlášeno. Protože implicitně spojuje git.
Krok sloučení ovlivní váš místní rozvoj a může způsobit konflikty
V zásadě to NENÍ bezpečné. Je to agresivní.
Na rozdíl od git fetch, kde to ovlivňuje pouze vaše .git / refs / remotes, git pull ovlivní jak vaše .git / refs / remotes, tak .git / refs / heads /
Hmmm ... takže pokud neaktualizuji pracovní kopii pomocí git fetch, kde tedy provádím změny? Kam ukládá Git fetch nové provize?
Skvělá otázka. Dává to někam izolovaně od vaší pracovní kopie. Ale zase kde? Pojďme to zjistit.
V adresáři projektu (tj. Kde provádíte své příkazy git) proveďte:
je. Zobrazí se soubory a adresáře. Nic super, já vím.
Nyní udělejte ls -a. Zobrazí se tečkované soubory, tj. Soubory začínající na. Poté uvidíte adresář s názvem: .git.
Udělejte cd .git. To samozřejmě změní váš adresář.
Nyní přichází ta zábavná část; dělám to Zobrazí se seznam adresářů. Hledáme doporučení. Do cd refs.
Je zajímavé sledovat, co je ve všech adresářích, ale zaměřme se na dva z nich. hlavy a dálkové ovladače. Pomocí cd zkontrolujte také jejich vnitřek.
Jakýkoli git fetch, který provedete, aktualizuje položky v adresáři /.git/refs/remotes. V adresáři /.git/refs/heads se nic neaktualizuje.
Jakýkoli git pull nejprve provede git fetch, aktualizuje položky v adresáři /.git/refs/remotes, poté se spojí s vaším lokálním a poté změní hlavu v adresáři /.git/refs/heads.
Velmi dobrou související odpověď najdete také v části Kde se místo „git fetch“ umístí ?.
Hledejte také „Slash notaci“ v příspěvku konvence pojmenování větve Git. Pomůže vám lépe pochopit, jak Git umisťuje věcirůzné adresáře.
Chcete-li vidět skutečný rozdíl
Stačí udělat:
git fetch origin master
git pokladna master
Pokud byl vzdálený master aktualizován, zobrazí se zpráva jako tato:
Vaše větev je za „původem / pánem“ o 2 závazky a může být rychle vpřed.
(použijte "git pull" k aktualizaci vaší místní pobočky)
Pokud jste nenačetli a právě jste provedli git checkout master, pak by váš místní git nevěděl, že jsou přidány 2 revize. A to by jen řeklo:
Již na „pánovi“
Vaše pobočka je aktuální s „origin / master“.
Ale to je zastaralé a nesprávné. Je to proto, že git vám poskytne zpětnou vazbu pouze na základě toho, co ví. Na nové závazky se zapomíná, že to ještě nestáhlo ...
Existuje nějaký způsob, jak zobrazit nové změny provedené ve vzdáleném při místní práci na pobočce?
Některé IDE (např.Xcode) jsou super chytré a používají výsledek git fetch a mohou anotovat řádky kódu, které byly změněny ve vzdálené větvi vaší aktuální pracovní větve. Pokud byl tento řádek změněn jak lokálními změnami, tak vzdálenou větví, bude tento řádek anotován červeně. Toto není konflikt sloučení. Je to potenciální konflikt sloučení. Je to headsup, který můžete použít k vyřešení budoucího konfliktu sloučení před provedením git pull ze vzdálené větve.
Zábavný tip:
Pokud jste načetli vzdálenou větev, např. dělal:
funkce git fetch origin / 123
Pak by to šlo do vašeho adresáře dálkových ovladačů. Ve vašem místním adresáři stále není k dispozici. Zjednodušuje však vaši pokladnu na tuto vzdálenou větev pomocí DWIM (Udělejte, co mám na mysli):
funkce git checkout / 123
už nemusíte dělat:
git checkout -b feature / 123 origin / feature / 123
Více informací najdete zde
|
Jediný rozdíl mezi git pull a git fetch je ten, že:
git pull vytáhne ze vzdálené větve a sloučí ji.
git fetch načte pouze ze vzdálené větve, ale nesloučí se
tj. git pull = git fetch + git merge ...
|
Git umožňuje chronologicky použít starší revize po novějších revizích.
Z tohoto důvodu je akt přenosu závazků mezi úložišti rozdělen do dvou kroků:
Kopírování nových závazků ze vzdálené větve do kopie této vzdálené větve v místním repo.
(operace repo na repo) master @ remote >> remote / origin / master @ local
Integrace nových závazků do místní pobočky
(operace uvnitř repo) remote / origin / master @ local >> master @ local
Krok 2 lze provést dvěma způsoby. Můžete:
Rozvětvte místní větev po posledním společném předkovi a přidejte nové revize paralelně ke revizím, které jsou jedinečné pro místní úložiště, finalizované sloučením revize, zavřením vidlice.
Vložte nové revize za posledního společného předka a znovu aplikujte revize jedinečné do místního úložiště.
V terminologii git je krok 1 git fetch, krok 2 git merge nebo git rebase
git pull je git fetch a git merge
|
Git získá větev nejnovější verze ze vzdáleného do lokálního pomocí dvou příkazů:
git fetch: Git získá nejnovější verzi ze vzdáleného na místní, ale automaticky se nespojuje.
git fetch origin master
git log -p master..původ / master
git merge origin / master
Výše uvedené příkazy znamenají stažení nejnovější verze hlavní větve z počátku ze vzdálené do původní větve. A pak porovná místní hlavní větev a původní hlavní větev. Nakonec sloučit.
git pull: Git získá nejnovější verzi z dálkového ovladače a sloučí se do místní.
git pull origin master
Výše uvedený příkaz je ekvivalentní k git fetch a git merge. V praxi je git fetch možná bezpečnější, protože před sloučením můžeme vidět změny a rozhodnout se, zda se mají sloučit.
|
Jaký je rozdíl mezi git pull a git fetch?
Abyste tomu porozuměli, musíte nejprve pochopit, že váš místní git udržuje nejen vaše místní úložiště, ale také udržuje místní kopii vzdáleného úložiště.
git fetch přináší místní kopii vzdáleného úložiště aktuální. Například pokud je vaším vzdáleným úložištěm GitHub - možná budete chtít načíst všechny změny provedené ve vzdáleném úložišti do vaší místní kopie vzdáleného úložiště. To vám umožní provádět operace, jako je porovnání nebo sloučení.
git pull na druhé straně způsobí změny ve vzdáleném úložišti, kde si ponecháte svůj vlastní kód. Obvykle git pull nejprve provede git fetch, aby místní kopii vzdáleného úložiště aktualizoval, a poté sloučí změny do vašeho vlastního úložiště kódu a případně do vaší pracovní kopie.
|
git pull == (git fetch + git merge)
git fetch se nezmění na místní pobočky.
Pokud již máte místní úložiště se vzdáleným nastavením pro požadovaný projekt, můžete pomocí git fetch popadnout všechny větve a značky pro existující vzdálený. ... Fetch nedělá žádné změny v místních pobočkách, takže budete muset sloučit vzdálenou větev se spárovanou místní pobočkou, aby se začlenily nově načtené změny. z github
|
Jednoduché grafické znázornění pro začátečníky,
tady,
git pull
načte kódz úložiště a rebase s místním ... v git pull existuje možnost vytvoření nových závazků.
ale v ,
git načíst
načte kód z úložiště a musíme jej ručně rebase pomocí git rebase
např .: chystám se načíst z hlavního serveru a rebase v mém místním hlavním.
1) git pull (rebase se provede automaticky):
git pull origin master
tady původ je váš vzdálený repo master je vaše pobočka
2) git fetch (je třeba rebase ručně):
git fetch origin master
načte změny serveru od počátku. a bude ve vaší místní síti, dokud ji sami nezměníte. musíme opravit konflikty ručně kontrolou kódů.
git rebase origin / master
toto přesměruje kód na místní. předtím se ujistěte, že jste ve správné větvi.
|
Snaží se být jasný a jednoduchý.
Příkaz git pull je ve skutečnosti zkratka pro git fetch, po které následuje git merge nebo příkaz git rebase v závislosti na vaší konfiguraci. Úložiště Git můžete nakonfigurovat tak, aby git pull byl načtením následovaným rebase.
|
Git ve skutečnosti udržuje kopii vašeho vlastního kódu a
vzdálené úložiště.
Příkaz git fetch zaktualizuje vaši místní kopii získáním dat ze vzdáleného úložiště. Důvod, proč to potřebujeme, je ten, že někdo jiný mohl provést nějaké změny v kódu a vy se chcete nechat aktualizovat.
Příkaz git pull přináší změny ve vzdáleném úložišti tam, kde si ponecháte svůj vlastní kód. Normálně to git pull dělá tak, že nejprve provede „git fetch“, aby místní kopii vzdáleného úložiště aktualizoval, a poté sloučí změny do vašeho vlastního úložiště kódu a případně do vaší pracovní kopie.
|
1
2
další
Vysoce aktivní otázka. Získejte 10 reputace, abyste mohli odpovědět na tuto otázku. Požadavek na reputaci pomáhá chránit tuto otázku před spamem a neodpovědností.
Toto není odpověď, kterou hledáte? Přečtěte si další otázky týkající se značek git version-control git-pull git-fetch nebo položte vlastní otázku.